perm filename GRAY.LST[MF,DEK]1 blob sn#749690 filedate 1984-04-08 generic text, type T, neo UTF8
  1) GRAY.TEX[MF,DEK] and 2) GRAY.TEX[1,DRF]	4-08-84 13:11	pages 1,1

**** File 1) GRAY.TEX[MF,DEK]/1P/20L
1)	array of rectangles; hence the symbol $x$ often has a somewhat gray
1)	appearance, although any symbol can actually be used.
1)	In order to construct such proofs, \.{GFtoDVI} needs to work with
**** File 2) GRAY.TEX[1,DRF]/1P/20L
2)	array of rectangles; hence it is best to chose a symbol for $x$ that
2)	has a somewhat gray appearance, although any symbol can actually be used.
2)	In order to construct such proofs, \.{GFtoDVI} needs to work with
***************


**** File 1) GRAY.TEX[MF,DEK]/1P/31L
1)	If proofs will relatively large pixels are desired, a two-character
1)	gray font is all that's needed. However, if the pixel size is to be
**** File 2) GRAY.TEX[1,DRF]/1P/31L
2)	If proofs with relatively large pixels are desired, a two-character
2)	gray font is all that's needed. However, if the pixel size is to be
***************


**** File 1) GRAY.TEX[MF,DEK]/1P/42L
1)	The character $x$ always appears in position~1 of a gray font. It
1)	must have positive height~$h$ and positive width~$w$; its depth
**** File 2) GRAY.TEX[1,DRF]/1P/42L
2)	On the other hand, many printing devices are not able to cope with
2)	arbitrarily large or complex characters, so it is not possible for a
2)	single gray font to work well on all machines.  Consider also the fact
2)	that $x$ must have a width that is an even multiple of the printing
2)	device's unit of horizontal position, since rounding the positions of grey
2)	characters would result in unsightly streaks on proof output.  Thus, there
2)	is no way to make the gray font as device independent as the rest of the
2)	system.
2)	This understood, we can now take a look at what \.{GFtoDVI} expects to
2)	see in a gray font. The character $x$ always appears in position~1. It
2)	must have positive height~$h$ and positive width~$w$; its depth
***************